As more services and information become available over the Internet, the number of users that access the Internet and use these services increases. These users have a variety of choices in selecting which web sites to use for services such as travel planning, online banking, news reporting, etc.
With the variety of services available, a user may have many choices of providers to use for a particular Internet service. Thus, a company providing a service over the Internet should do whatever possible to distinguish itself from its competitors and ensure that it is providing a positive user experience through its web service. To achieve this, some web service providers monitor the provided web service to determine any problems or delays in providing the service to users.
Previously, performance of a web service was monitored by adding a component between the client device and an application server. The component determines times between transmission events for the client device and application server. However, the interposed component introduces additional delays in the communication between the client device and the application server.
Another previous system for monitoring web service performance captures times associated with server-side events during communication with a client device. An application server of the server-side time capture system receives a content request from a client device. After receiving the request, the server generates a content response which includes page load notification code and sends the response to the client device. An Internet browser at the client loads the content in the response and executes the page load notification code. When the content loading is completed, the code sends a page load notification message to the application server. The application server then determines the response time for the web service as the difference between the time the content request was received and the time the page load notification message was received at the application server.
The server-side time capture system for monitoring a web service shall be discussed in more detail. The system includes a client device, an application server, an agent and a manager application. The client device includes an Internet browser (or browser application). The content request is initiated by the browser application on the client in response to receiving user input. The time at which the server receives the request from the client is stored by the server. The server then generates a content response for the request. The content response includes requested content, a response identifier and page load notification code. The server sends the generated response to the client device. The page load notification message sent after content has been loaded includes the response identifier and is in the form of an image content request. When the server receives the page load notification message, it captures the current time at the server. The server-side captured response times are then sent to an agent module. The agent module aggregates the response time information and forwards aggregated response time information to a manager application.
The application server generates the response using a servlet and servlet filters. A custom servlet filter is used to insert the page load notification code into the response. Bytecode generation is used to generate the custom servlet filter within an application. To generate the filter, an application management tool may instrument the application's object code (also called bytecode). An application uses probes to access information from the application. A probe builder instruments (e.g. modifies) the bytecode for the application to add probes and additional code to the application. By adding the probes, the application becomes a managed application. The probes may measure specific pieces of information about the application without changing the application's business logic. The probe builder also generates the agent module. The agent may be installed on the same machine as the managed application or a separate machine. More information about instrumenting byte code can be found in U.S. Pat. No. 6,260,187 “System For Modifying Object Oriented Code” by Lewis K. Cirne, and U.S. patent application Ser. No. 09/795,901, filed Feb. 28, 2001, entitled “Adding Functionality to Existing Code at Exits,” having inventor Jeffrey Cobb, both of which are incorporated herein by reference in its entirety. In one embodiment, the technology described herein does not actually modify source code. Rather, the present invention modifies object code. The object code is modified conceptually in the same manner that source code modifications are made.
To configure the application server of the server-side time capture system to process requests, the application server is initialized. After the server is initialized, application servlet filters are loaded and instantiated into servlet containers. To load and instantiate the application servlet filters, an application server configuration file is accessed and loaded to determine the current servlet filters associated with the application servlet container. Once the current servlet filters are determined, additional servlet filters are added into the servlet filter chain. The custom servlet data is added to a configuration file entitled, “web.xml” of the application server. The custom servlet filter data is added such that custom servlet filter is the first to process a content request for a servlet and last to process an outgoing content response from a servlet. The application server configuration file with modified servlet chain data is stored as an object in the application server memory.
The application file on the application server is then initialized, and the stored application server configuration file is read. The configuration file is read by the servlet container in preparation for instantiating servlets and servlet filters. Individual servlet filter class files are then loaded and instantiated. The individual servlet filter class files include both custom servlet class files and pre-existing servlet class files. This creates a data structure of servlet filters which will be used to process incoming content requests. Next, request templates for a servlet and servlet filter chains are generated and cached. Templates consisting of a chain of processing servlet filters and servlets are generated for particular URLs.
When a content request is received by the configured application server, the server generates a content response. The content response is generated at the application server by a servlet and a chain of one or more servlet filters. Once the content request is received by the application server, the server generates a request object and a response object. The request and response objects are routed through the chain of servlet filters and then to the servlet. The servlet generates the response from the response object, and the response is routed through the servlet filters again before being sent to the requesting client device.
The servlet filter chain includes a custom servlet filter inserted by bytecode instrumentation. When the request is routed through the servlet filters to the servlet, custom servlet filter assigns a request identifier to the request. The request identifier is stored with the request as it is processed by the servlet and servlet filters. The request identification number and corresponding servlet identification information are stored in a servlet table. The custom servlet filter also wraps the response object in a wrapper. The response object wrapper detects whether a writing object or output stream is used to generate the body of the response and can provide that information to a requesting entity.
When processing the response generated by the servlet, the custom servlet filter adds JavaScript page load notification code to the response. When adding the page load notification code to the content response, the custom servlet filter confirms the response is in HTML and whether the response was written using an available writer or an output stream. The custom servlet determines if the response is in HTML by placing a call to a response object method for retrieving a Multi-Purpose Internet Mail Extension (MIME) type of the response object. The response from the get MIME type method indicates whether the MIME type is HTML or some other format. If the response is determined to be HTML, a Get Writer query is made to the response object wrapper. The page load notification code is then written to the response using either an output stream if used to generate the response, the writer used to generate the response, or an alternative writer that may be used to write to the response. If the response is not in HTML or there is no writer available to write code to the response which was generated with a writer, then the code is not inserted into the response by the custom servlet filter.
After writing the response, the response is sent to the client device. The client device receives the response and provides the response to the browser application. The page load notification code is then registered with the browser application and executed. When executed, the page load notification code registers a function with an On Load event handler at the browser application.
When an On Load handler already exists, the page load notification code places the function before the existing code in the On Load handler such that the added code is executed first. The function is JavaScript code that, when executed, sends a page load notification message to the application server. The page load notification message includes the request identification information assigned to the response by the custom servlet filter. The page load notification code is executed upon the detection of a browser application On Load event.
The page load notification message is in the form of an image source request message. Thus, the message requests image data from the application server. The message includes the request identification information in the name of the site request, such that the message is sent to: HTTP://(site)/ID=A, wherein A is the request identification information. The receiving application server “site” extracts the request identification information included in the site link and transmits a response to the image source request. The response is a transparent image having a 1×1 pixel array.
After the client device sends the page load notification message, the application server receives the message. The application server routes the received message to the appropriate processing servlet within the application server. The application server determines the appropriate servlet by retrieving the servlet identifier from the servlet identification table which is associated with the request identification information in the response. The processing servlet determines the time the page load notification message was received, determines the response time based on server side events, and sends an image content response to the browser application. The image content response includes a transparent 1×1 pixel matrix.
After processing the response, the servlet sends the time response to the agent application. The agent application then stores and aggregates the received time data. The aggregated time data is then sent to the manager application. The data may then be reported by the manager application to a workstation or database. The manager application receives performance data from managed applications via the Agent application, runs requested calculations, makes performance data available to workstations and optionally sends performance data to a database for later analysis. The workstations are the graphical user interface for viewing performance data. The workstations are used to create custom views of performance data which can be monitored by a human operator. The workstations consist of two main windows: a console and an explorer. The console displays performance data in a set of customizable views. The explorer depicts alerts and calculators that filter performance data so that the data can be viewed in a meaningful way.
The server-side time capture system is able to capture server-side information related to web service response time, but is not able to accurately determine the actual response time involved with a web service which provides content to a user at a client device. Rather, the server-side time capture system approximates the response time by recording times at the server that are associated with communications with the client device. Furthermore, the server-side time capture system used to determine response times (estimated from the server's point of view) for user-initiated requests to different URLs is an undesirable system for determining a benchmark response time for each URL. Accurate assessment of web service performance is important to evaluating the service provided to users.